Add sample stream and release metadata, and release index #207
Conversation
metadata/release-index.json
Outdated
| @@ -0,0 +1,17 @@ | |||
| { | |||
There was a problem hiding this comment.
should we include stream name in release-index.json as well? Can be useful to figure out stream while looking at the json file.
There was a problem hiding this comment.
The release-index is inside of a stream specific location (e.x.: s3://fcos-builds/prod/streams/<stream>/release-index.json)
There was a problem hiding this comment.
Followup: the release-index is also specific to an architecture. Thus, architecture label should be part of the location, or somewhere in the index.
There was a problem hiding this comment.
@lucab: Reading the code again with more coffee leads me to believe that I misread something earlier and that is not the case currently.
Each entry in release-index points to an endpoint for the release.json which IS stream specific but is NOT architecture specific.
e.x.:
s3://fcos-builds/prod/streams/foo/release-index.json is the release-index for the foo stream. An example entry would be something like:
{
"commit": "<hash>",
"version": "30.123.45",
"endpoint": "https://fcos-builds.s3.amazonaws.com/prod/streams/foo/builds/30.123.45/release.json"
}
metadata/release-index.json
Outdated
| { | ||
| "releases": [ | ||
| { | ||
| "commit": "<hash>", |
There was a problem hiding this comment.
From comment #98 (comment), I believe commit and version we are referring here is ostree commit and version. One thing to note that, we will have same ostree version number for a release across all arches but commit hash will be different for different arches.
There was a problem hiding this comment.
None of these fields are unique, we can have different commits with the same version and it won't conflict.
to avoid confusion over naming.
|
Renamed release index sample to reduce confusion. Will address other comments next week. |
metadata/stream.yaml
Outdated
| # slug is the best we can do. | ||
| image: fedora_coreos_stable | ||
|
|
||
| updates: |
There was a problem hiding this comment.
I'm unsure about the indentation of this. I don't think we want to have different update metadata for each architecture, to avoid exploding RelEng complexity. If so, I think this can become a top-level section on its own.
There was a problem hiding this comment.
Yeah, in hindsight that choice seems somewhat arbitrary. If we want different update targets for different arches, presumably we'd also want them for different platforms. I don't want to introduce that level of complexity right now, so I'll switch this to a single value.
Might as well keep the document self-contained.
It seems more important to distinguish per-platform targets than per-arch ones, and that would introduce a lot of complexity. So, for now, keep a single update target for the entire stream.
|
Updated. |
From #98.